COMMENTS 



The enclosed is responsive to the Examiner's Office Action mailed on June 6, 2007. At 
the time the Examiner mailed the Office Action claims 1-9, 10-18, 19-28 and 30 were 
pending. By way of the present response the Applicants have: 1) amended claims 1,11 and 
21; 2) added no new claims; and 3) not canceled any claims. As such, claims 1-9, 10-18, 19- 
28 and 30 remain pending. The Applicants respectfully request reconsideration of the 
present application and the allowance of all claims now presented. 

In the Office Action mailed on 6/6/07 the Examiner maintained a rejection of all 
independent claims as being anticipated by the Conti reference. In order to further advance 
the present application towards allowance, the Applicant has amended each of the 
independent claims to further emphasize a significant architectural difference between the 
teachings of the present application and the Conti reference. 

Specifically, the Examiner's attention is drawn to the opening discussion of the teachings 
of the present application presented in paragraphs [0033], [0034] and [0036] of the 
Applicant's specification where the following statements are made (emphasis added) 

[0033] The monitoring approach of Figure 2 is an exemplary depiction that applies 
software monitoring techniques to the particular IS arrangement originally depicted in 
Figure 1. According to the monitoring techniques depicted in Figure 2, a Generic 
Request Message Generation (GRMG) infrastructure unit 209 is responsible for 
repeatedly sending a GRMG request message 21 1 (hereinafter, "request message") to a 
GRMG application 210 . The request message 21 1 identifies the various software 
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components of a higher level "scenario". For example, in a typical implementation, the 
"scenario" might correspond to a business logic process that invokes a number of lower 
level software components (i.e., any one or more of: processes, programs, web pages); 
and, the request message 211 for the scenario identifies each of these components. 

[0034] The GRMG application 2 10 is a unit of software that is designed to receive the 
request message 21 1 and "check into" the availability of each of the software components 
that are identified by the request message 211. The results of the inquiries into the 
software components are collected and placed into a GRMG response message 212 
(hereinafter "response message") . For example, a functional disposition (e.g., "OKAY" 
or "ERROR") for each of the scenario's software components is included in the response 
message 212. 

[0036] After the GRMG application 210 forms the response message 212, it is sent to 
the GRMG infrastructure 209 . In the particular embodiment of Figure 2, the response 
message 212 is sent by the servlet engine 205 to the web server 204; which, in turn, 
forwards the message into the network 201. The GRMG infrastructure 209, in response 
to its reception of the response message 212, provides the availability test results that 
were expressed within the response message 212 to software that is responsible for 
generating images on a display 216. The results are then graphically depicted on the 
display 216 (e.g., in an "alert monitor tree" 215) so that an IS administrator can visually 
determine the status of the scenario (which, as discussed, may represent a business logic 
process). 



Thus, the Applicant's specification teaches a testing scenario architecture that includes a 
form of testing "controller" (GRMG infrastructure 209) that: 1) coordinates the execution of 
the testing scenario by repeatedly, during live testing, sending request messages to a 
server/servlet engine to test the availability of one or more of its corresponding software 
component(s); and, 2) coordinates the test results by receiving response messages (from the 
aforementioned server/servlet engine) that report the availability of the software 
component(s). 

The Conti system has no such controller. In the Conti system, each of the testing agents 
14a - 14n execute "testing scripts" to simulate multiple users of the web-server under test. 
See, Conti, col. 3, lines 2-15. It is clear that in the Conti system, only the testing agents 14a 
- 14n repeatedly send requests during live testing to the server being tested . Notably, 
however, the tests results responsive to these requests are accumulated in a database system 

that is local to the server under test. See, Conti, col. 6, lines 38-57 (describing the 
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accumulation of test result data in "DB2 Stats table 132"); id., col. 3, line 46 to col. 4, line 11 
(describing "stats" table 132 as being part of "DB2 product 25" of Fig. 1). Thus, the results 
of the testing are not reported back to the testing agents 14a - 14n. Therefore Conti does not 
describe a system in which an entity that repeatedly, during live testing, sends requests to a 
server whose software is being tested is also reported back to with the results of the tests. 

By contrast the present application describes such a system and the currently presented 
claims recite its pertinent features (albeit from the testing application side that is opposite the 
controller entity). In particular the Applicant's independent claims now recite 



repeatedly receiving request messages at a testing application running on a server or servlet engine, 
said repeatedly receiving occurring during execution of a testing scenario , each of said request 
messages identifying the same set of software components . . . 

said testing application, in response to each of said request messages in executing said testing 
scenario, performing the following: 

testing each of said one or more software components for availability and 
preparing and sending onto a network a response message to report availability or 
unavailability for each of said one or more software components to an entity that sent said 
response messaged corresponding request message. wherein 4 at least one of said software 
components requires a login procedure for its availability test and each of said request 
messages include a userid for said login procedure. 



Thus the Applicant respectfully submits that the claims are presently in allowable form and 
respectfully requests the allowance of same. 



Closing Comments 



Because the Applicant has demonstrated the patentability of all pending independent 
claims, the Applicant respectfully submits that all pending claims are allowable. The 
Applicant's silence with respect to the dependent claims should not be construed as an 
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admission by the Applicant that the Applicant is complicit with the Examiner's rejection of 
these claims. Because the Applicant has demonstrated the patentability of the independent 
claims, the Applicant need not substantively address the theories of rejection applied to the 
dependent claims. 

In the further interests of efficiency, the Applicant reserves the right under MPEP 
2 144.03. C to cause the Examiner to find in the prior art subject matter to which the Examiner 
has taken Official Notice at a later time in the prosecution of the present case when the 
subject matter of such prior art is actually at issue. 

If there are any additional charges, please charge Deposit Account No. 02-2666. If a 
telephone interview would in any way expedite the prosecution of this application, the 
Examiner is invited to contact Robert B. O'Rourke at (408) 720-8300. 



Respectfully submitted, 

BLAKELY/^ONOLOFF, TAYLOR & ZAFMAN LLP 




Dated: 



Robert B. O'Rourke 
Reg. No. 46,972 



1279 Oakmead Parkway 
Sunnyvale, CA 94085-4040 
(408) 720-8300 
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